COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	featur[e85,jmc]		New programming language features
C00011 ENDMK
C⊗;
featur[e85,jmc]		New programming language features

	Programming a computer in English is possible; so is
controlling an airplane with reins and spurs.   The known
programming language features are just as useful for describing
algorithms as mathematical notation is for expressing mathematical
facts.  Nevertheless,
English and other natural languages have many features that
it would be valuable to have in programming languages.  The
first problem is to identify them, but some of them will require
some AI to realize even when identified.  The object of this
paper is to propose some new features for programming languages.
The ideas for most of them come from introspecting about natural
language communication, but some of them come from mathematics.

Abstract actions:

elephant

Program modification language

	The first idea I want to discuss, partly coming from
natural language considerations and partly from observing
the programming process, is that the activity of a programmer
consists more in modifying programs than in writing them
{\it ab initio}.  Therefore, I discuss the more general notion
of program modification language; an ordinary programming
language provides only for modifying the null program.

	Much of the difficulty in modifying a program
compared to modifying the behavior of a person is that
the programmer has to understand the program he is modifying
to a far greater extent than does one person
instructing another about an improved way of doing something.
Therefore, in so far as possible, we want to be able to modify
programs without reading them.

	How can this be possible?

	Consider the following example.  The head of an airline
wants the reservation system modified.  He tells his underlings,
``Don't sit Iraqis next to Iranians; they might fight''.  In order
to modify the reservation system to meet this requirement, the
programmers have to understand the data structures used by the
reservation system.  Perhaps they have to expand it to include
a field for the nationality of the passenger and provide for
asking for this nationality.  Even if the field already exists,
they may have to know where it is.  Why can't the programmers
modify the program with the same lack of knowledge that the
airline boss had in instructing them?

	Here is one idea.

Abstract actions, commitments, data structures considered harmful, and direct
reference to the past

	Consider the action of reserving a seat for a passenger.
Our proposal will be most spectacular if we don't require a
specific seat but merely require that he be let on the airplane.
In present programming languages, except possibly Prolog looked
at in an unusual way, reserving a seat means making an entry
in a specific data structure.  Our proposal is to regard this
as an {\it abstract action} with no definite event corresponding
to it in the semantics of the language.  Its only consequence
is that another part of the program says that the passenger
must be allowed on the airplane if he has a reservation.  Almost
always the compiler will have to realize the act of reserving
a seat by making an entry in a data structure, but we can imagine
other possibilities.  First, the system may know that a particular
flight will not be full, or be willing to chance it.  In this
case, no concrete action need be taken corresponding to the
abstract action of reserving a seat, because the passenger is
sure to be allowed on the airplane anyway.

	A programming language that allows abstract actions must
also allow reference to the past.  The part of the program that
decides whether to admit a passenger to the airplane refers to
the past event of reserving a seat for him.  Actually it has
must refer to the state of having a reservation, since reservations
can be cancelled, remade and cancelled again.  The state of
there being a reservation for a passenger is an abstract state
with no specific necessary correlate in the memory of the computer.

	Let's relate this to the problem of modifying the reservation
program without reading it --- or at least reading as little as
possible of it.  This depends on programming as much as possible
in public terminology, e.g. the original writer and the modifier
of the program must both refer to reservations.  It may be that
they could get by with their common understanding of the English
word ``reservation'' together with a common use of the programming
terminology of abstract actions.  More likely, they might have
to use a pre-established airline jargon in which ``reservation'',
``passenger'', etc. are technical terms.

	There has been some discussion of whether abstract actions
should be considered as belonging to the program itself or to its
specifications.  If one has a system that goes automatically from
specifications to program, the difference seems to be only terminological.
Otherwise, I believe that abstract actions are compilable and hence
belong in the program itself.

Commitments:

	A particular form of abstract action is the {\it commitment}.
In the reservation case, the act of reserving a seat can be regarded
as making a commitment to let the passenger on the airplane when he
appears.  This is advantageous if we can divide the actions of the
program into outputs and commitments.  A program is correct if it
fulfills its commitments.